Evolutionary Architecting of Software-Intensive Systems

Most industrial software-intensive systems have a very long life span, and undergo many changes after their initial conception. To ensure that they maintain the desired system-level properties, it is essential that their architecture is also updated to reflect the added functionality. To this end, we have investigated how Evolutionary Architecting should be carried out in order to provide a strong basis for a system, not only at conception but throughout its life. The results are concrete and based on empirical findings, and include both a new state-of-the-art process description and a lightweight maturity evaluation method. Embedded software is a critical component to be considered in the development of many new products such as cars, airplanes, industrial robots, and telecommunications systems. There is great scope for innovation within software , and innnovative software can keep a product competitive. Often, a product line approach is used, where many variants are spawned off the same platform over decades. However, with separate teams working on different products and modifying the platform to suit their needs, coordination between them becomes essential to ensure that the platform keeps its integrity and stays useful for future needs. It is a central role of the architects to maintain this integrity and provide technical prerequisites for the different design teams. Plenty of research has been done on software and systems architecture, but much of it focuses on the development of new systems. However, our empirical research shows that evolution of existing products is much more common than new development. Therefore, through interviews and surveys with around 100 active architects at a dozen companies, we have tried to identify needs and challenges within architecting to support the evolutionary development of embedded software. Many of the organizations suffer from unclear processes and responsibility for architecture, and lack methods to evaluate the business value when making architectural decisions. In short, the companies rely on individuals instead of on processes and methods. These issues are typical signs of imma-turity in architecting organizations. To identify where improvements can be made, it is useful to have a way of assessing an organization's maturity. Several well-known maturity models exist, such as Capability Maturity Model Integration (CMMI), which captures the best practices for development in general. However, it has a few drawbacks when applied to architecting. Firstly, it is heavy to use for a small team, and secondly , it emphasizes formal appraisals by external assessors, whereas …